Aggregation Levels in Composable Architectures

The creation of a Product Family is an alternation of decomposition and synthesis steps. Composable architectures emphasize the composition of products, decreasing the importance of a priori decomposition. The products and intermediate compositions can be viewed as recursive aggregation levels. Careful tradeoffs are required between the size of an aggregation level and the way it will be deployed. Flexibility and (configuration) manageability amongst others are balanced. This article shows multiple viewpoints with respect to aggregation levels, the concerns per viewpoint and the relevant entities per viewpoint. For every viewpoint heuristics are given for the level of granularity. This article is to be used in the "Family Engineering Handbook", a collective effort of Philips Research employees to consolidate family engineering based experiences. Distribution This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the document remains complete and unchanged. All Gaudí documents are available at: http://www.extra.research.philips.com/natlab/sysarch/ version: 2.2 status: draft 24th September 2001 1 Problem description This article is focusing on ”composable architectures”. Composable architectures are designed for a single application domain, enabling the composition of products of which the definition is still evolving or hidden in the future. A crucial design question is: What is the desired granularity of the design, what are useful abstractions? The granularity of the design is directly related to the question: What are the appropriate aggregation levels for composition and integration? Most Product Creation Processes are based on a single dominating decomposition and integration model. This oversimplification causes many problems for development. This article decribes an approach based on multiple viewpoints, matching the wide variety of concerns involved. Per viewpoint heuristics are given. Application of a multiview approach requires customization of viewpoints and concerns. In general this means identification of the most relevant, important of critical issues, which are used to select a small manageable amount of viewpoints as main focus. 2 Views on Aggregation Product Creation Integration and Test Documentation Source Code Management Composition Deployment Figure 1: Venn diagram showing the overlap between Viewpoints on Aggregation Levels Figure 1 shows a Venn diagram with 5 viewpoints with respect to aggregation levels, in the overall context of Product Creation. For every viewpoint the dominating concerns are mentioned in table 1 and the related aggregation levels or entities in table 2. All entities in Documentation, Repository, Composition and Deployment are relevant for the Integration and Test viewpoint. Gerrit Muller Aggregation Levels in Composable Architectures 24th September 2001 version: 2.2 Philips Research IST-SWA-IA page: 1 Viewpoint Concerns Documentation Requirements, Specification, Design, Transfer, Test, Support Source Code Management Storage, Management, Generation Composition System, Subsystem, Function, Application Deployment Releasing, Distribution, Protection, Update, Installation, Configuration Integration and Test Confidence, Problem Tracking Table 1: Concerns per viewpoint Viewpoint Entities Documentation Product Family, Product/System, Function/Feature, Subsystem, Component, Building Block, Module Source Code Management Package, File Composition Product, Executable, Dynamic Library, Component Deployment Distribution Medium (”CD”), Unit of Licensing (”SW key”), Package, Patch, Configuration data Integration and Test Test Configurations, Intermediate Integration results Table 2: Aggregation Levels or Entities per viewpoint